Generic transport networks, such as OTN (Optical Transport Network), SDH (Synchronous Digital Hierarchy) or SONET (Synchronous Optical NETwork) networks, are widely used for transmission of large data streams (e.g. a large number of telephone channels) between network elements in the telecommunications networks. These synchronous systems also allow the transmission of asynchronous signals, e.g. signals from a PDH (Plesiochronous Digital Hierarchy) with data rates of 140 Mbit/s, 34 Mbit/s or 2 Mbit/s, which may be mapped into e.g. a SDH system.
International standards prescribe how to place the individual bytes in the frames of the synchronous system. A detailed structure shows how this mapping is made. In the SDH system the payload data signals are placed together with overhead signals in so-called virtual containers, which may be higher order virtual containers, e.g. VC-4, or lower order virtual containers, e.g. VC-12 or VC-3.
SDH signals are a serial flow of logical 1's and 0's that may be subdivided into a sequence of bytes of 8 bits each. The signals are structured such that the transmitted bit flow may be subdivided into a plurality of channels for different applications. The basic structure of an SDH signal is a so-called Synchronous Transport Module at level 1 (STM-1), which may be considered as a frame having 9 rows and 270 bytes in each row. Of the 270 bytes the first nine bytes in each row are used for overhead and pointers, so that 261 bytes in each row constitute the transport capacity of the frame. An STM-1 frame is transmitted with a data rate of 155.52 Mbit/s. Corresponding STM frames of higher order (STM-N) also exist, and these are transmitted with corresponding higher data rates. As examples, STM-4, STM-16, STM-64 and STM-256 are specified.
The signals are transmitted one row at a time with the uppermost row first, and each row is transmitted from the left to the right. Each byte is transmitted with the most significant bit first. The transport capacity of the STM-1 frame, i.e. the 9 rows of 261 bytes each, constitutes a higher order virtual container VC-4. The payload capacity of a VC-4 is 149.76 Mbit/s. For the lower order virtual containers, which may be mapped into the VC-4, the payload capacity is 49.536 Mbit/s for the VC-3 and 2.176 Mbit/s for the VC-12.
These bit rates are well suited for transporting e.g. PDH signals, which, as mentioned, the SDH system is frequently used for. In that case a VC-4 may e.g. contain a PDH channel of 140 Mbit/s, or it may be subdivided into a plurality of smaller virtual containers. It may e.g. contain 3 VC-3s each transporting a PDH channel of 34 Mbit/s or 63 VC-12s each transporting a PDH channel of 2 Mbit/s.
However, many services or data types require bit rates, which cannot utilize the possible bit rates of the virtual containers effectively. As an example, a data rate of 10 Mbit/s is required, when Ethernet data are transmitted through an SDH network. The smallest virtual container that will accommodate a 10 Mbit/s payload is a VC-3, which means that the transport efficiency is as low as 20%. Other data types with poor transport efficiencies in SDH are Fast Ethernet, ESCON, Fibre Channel and Gigabit Ethernet. The transport efficiency for such data types may be improved by concatenating virtual containers. Two types of concatenation exist, contiguous concatenation and virtual concatenation.
Contiguous concatenation is used when payloads greater than the capacity of e.g. a VC-4 is to be transmitted. In that case several containers may be locked to each other so that the concatenated containers are transmitted together through the network, in which the relevant network elements must be set up by the management system to handle the concatenated containers. As examples of contiguous concatenated containers, VC-4-4c, VC-4-16c and VC-4-64c can be mentioned. These containers can be transmitted in STM-4, STM-16 and STM-64 frames.
By virtual concatenation, the payload may be divided between a number of virtual containers in a more flexible way. For instance, Ethernet data of 10 Mbit/s may be transmitted in 5 VC-12 containers. Although the 5 containers constitute a Virtual Concatenation Group (VCG), they are transmitted as individual containers through the network, so that by virtual concatenation, there are no special requirements on the existing network elements or strict routing constraints for the network. The virtual containers of a VCG are also called the members of the group. In the receiving network element the virtual containers of the VCG can be recognized on their overhead, and a differential delay caused by difference in (optical) path length can be compensated, so that the data of the 5 containers can be combined again. Thus by means of virtual concatenation the transport efficiency is improved considerably, and network operators can implement connections that are more appropriate for the above-mentioned services by providing a much more flexible bandwidth granularity. Further, virtual concatenation is transparent to intermediate network elements, which means that it can be implemented without the need for any upgrade of the existing network elements.
Many of these services have variable requirements for bandwidth over time, and thus there is a need to be able to increase or decrease the capacity of a VCG link by adding or removing members from the group in order to meet the bandwidth needs of the application. The capacity of the VCG should be increased or decreased hitless, where a hit is a situation in which loss of data occurs. Further, in case a failure is experienced in the link for a member in the network, the transmission capacity needs to be decreased to avoid that the whole VCG fails. These functions can be handled by the Link Capacity Adjustment Scheme (LCAS) for virtual concatenated signals as specified by the ITU-T Recommendation G.7042/Y.1305. This Recommendation defines the required states at the source and at the sink side of the link as well as the control information exchanged between both the source and the sink side of the link to enable the flexible resizing of the virtual concatenated signal.
In LCAS, synchronization of changes in the capacity of the transmitter (source side) and the receiver (sink side) is achieved by control packets. Each control packet describes the state of the link during the next control packet. Changes are sent in advance so that the receiver can switch to the new configuration at a predefined time. The control packet consists of fields dedicated to specific functions. Control packets contain information sent from source to sink, i.e. the forward direction, and from sink to source, i.e. the return direction. The information in the forward direction comprises a control field providing commands indicating the status of the individual members of the group. The information in the return direction comprises an MST (Member Status) field, which reports the member status from sink to source with the two possible states OK and FAIL.
The network elements of a link are controlled by one or more management systems. The management system can instruct the end network elements, i.e. source or sink side, to add members to or remove members from the group. This is done by sending management messages.
The three main functions of the LCAS is to increase the VCG capacity by the addition of members, to decrease the VCG capacity by temporary removal of members due to a failure, and to decrease the VCG capacity by permanent removal of members due to a change in the bandwidth needs of the application.
However, in addition to the three main functions described above, there is often a need to be able to temporarily disable a member of the group from carrying payload. As an example, this will be needed when doing planned rerouting in the network. With the existing scheme this can only be done by first removing the member permanently, and then subsequently, when the rerouting has been done, adding that member again. However, in this way there is a risk that the channel that is added will not be the same as the one removed, or even that a channel is no longer available. Further, from a management point of view the two functions of removing a member permanently and disabling it temporarily are very different in nature. Thus the existing functions of the LCAS scheme are not suitable for disabling a member of the group only temporarily, while doing rerouting in the network.